The invention is directed toward a scripting language especially well adapted for writing scripts that (when run on a machine) generate, e.g., a liaison interface between a user and an existing user interface, and more particularly to such a scripting language that includes an integration construct data structure that permits commands from discrete user interfaces to be integrated in a single script (that when executed by a machine isolate the user from direct interaction with the discrete interfaces).
A script is a sequence of commands that are to be interpreted, i.e., executed by a program running on a processor, as contrasted with a program that is compiled into the machine code of a processor and then directly executed by that processor. A script can be generated using a text editor or a Graphical User Interface (GUI) adapted to the scripting language.
Large systems often include monitoring systems that permit one or more users to monitor the performance of the system in general, and to specifically monitor the state of one or more parameters of the large system. In some instances, the manner in which the monitoring system delivers information to the user can be a burden.
An example of the large system discussed above is a wireless communication network that provides wireless communications service to a wireless unit that is situated within a geographic region. A Mobile Switching Center (MSC) is responsible for, among other things, establishing and maintaining calls between wireless units and calls between a wireless unit and a wireline unit . As such, the MSC interconnects the wireless units within its geographic region with a public switched telephone network (PSTN). The geographic area serviced by the MSC is divided into spatially distinct areas called xe2x80x9ccells.xe2x80x9d In a schematic block diagram, each cell could be schematically represented by one hexagon in a honeycomb pattern. But, in practice, each cell has an irregular shape that depends on the topography of the terrain surrounding the cell. Typically, each cell contains a base station, which comprises the radios and antennas that the base station uses to communicate with the wireless units in that cell. The base stations also comprise the transmission equipment that the base station uses to communicate with the MSC in the geographic area via communication links. One cell site may sometimes provide coverage for several sectors. Here, cells and sectors are referred to interchangeably.
In a wireless cellular communications system, a base station and a wireless unit communicate voice and/or data over a forward link and a reverse link, wherein the forward link carries communication signals over at least one forward channel from the base station to the wireless unit and the reverse link carries communication signals on at least one reverse channel from the wireless unit to the base station. There are many different schemes for determining how wireless units and base stations communicate in a cellular communications system. For example, wireless communications links between the wireless units and the base stations can be defined according to different radio protocols, including time-division multiple access (TDMA), Frequency Division Multiple Access (FDMA), Code Division Multiple Access (CDMA) and others.
Within the geographic region, the MSC switches a call between base stations in real time as the wireless unit moves between cells, referred to as a handoff. Currently, in FDMA, TDMA, CDMA and GSM, cell site planning to determine the geographic coverage for a cell is a manually intensive task that needs constant adjustment. In planning a cell, the topology of the geographic area and a suitable antenna site is selected based on availability and zoning rules. Such a selection is typically not optimal but adequate. Drive tests and manually collecting signaling data are then performed mostly on the perimeter of the coverage area. Transmit and receive antennas and power are then adjusted in a manually iterative manner to improve the call quality. Sometimes, frequencies are swapped with neighbor cells and/or transmit power is readjusted to improve the coverage. Over time, the cell site engineers review customer complaints and cell site dropped call reports and again try to manually optimize the RF performance.
Lucent Technologies Inc. has developed a monitoring system that a user can use to change parameters of the wireless communication system as well as to extract data about it. This monitoring system can generate the TIpdunix (TI) interface, the Status Display Page (SDP) interface and/or the AUTOPLEX Recent Change and Verification Database (APXRCV) interface. These interfaces can be used individually. But typically, information extracted from one of the interfaces is used to make a decision to use a second one of the interfaces in one way or another. To use an interface, a user must start a discrete process. In a windows-based environment, each interface session has its own window.
These discrete or non-integrated interfaces to the monitoring systems pose problems for the user. Each interface has its own set of commands as well as formats for returning information to the user. These command sets and display formats are extensive. This burdens the user""s memory. Moreover, the SDP interface returns information in a manner that requires the user to interpret a combination of the foreground and background colors, as well as whether the associated text is blinking or not, in a particular region of the screen in order to determine the state of a component of a large system.
Based upon the information extracted from a first interface, the user must make a decision about whether it is appropriate to use a second interface and if so, the user must appropriately form the command to be submitted. Often, the first interface is used merely to verify that the large system is operating correctly. The user must inspect the data returned by the first interface to confirm that it is consistent with normal operation of the large system. If there is some discrepancy, it must be recognized by the user. Then, the user must determine the problem that is indicated by the discrepancy. Then, the user must take appropriate action, typically via one of the other interfaces.
While the user has the responsibility of confirming via one of the interfaces that the operation of the large system is normal, the user is essentially a prisoner to that interface. The user must continually confirm that the operation of the large system is normal by repeatedly extracting data from the large system. If the user fails to recognize a discrepancy in the data that is returned, then the user will have failed to recognize that there is a problem for which action must be taken.
In another instance, the user might use one of the interfaces to change a parameter in the large system. To confirm that the parameter change has taken effect, the user typically has to use a second interface. But there is typically a delay between the requested change of parameter and the time at which it takes effect in the large system.
To confirm that the change has taken effect, the user must repeatedly extract information from the large system via the second interface. Again, the user becomes a prisoner of the second interface until the user recognizes something in the data returned by the second interface that indicates the desired change has taken place.
Again, the TI, SDP and APXRCV interfaces each require a great deal of direct user interaction. An example of this is depicted in the unified modeling diagram of FIG. 1. FIG. 1 depicts interactions between a user 101 and a monitoring system 304 (to be discussed in more detail below concerning FIG. 3), to be discussed in more detail below. Communication from the user originate from a line 102, while communications from the monitoring system 304 originate from a line 104. The monitoring system 304 can generate the TI, SDP and/or APXRCV interfaces discussed above.
In the unified modeling diagram of FIG. 1, a user desires the result of executing an inventory command via the TI interface. To do so, the user might have to manipulate a field in the APX database in order to enable the use of an inventory command of the TI interface. First, the user must initiate an interface session with the APXRCV interface.
Then, the user must make a backup copy of the APXRCV database for the cell in consideration. Making the backup copy represents the first action requested by the user and it is requested via the APXRCV interface, i.e., the first interface. This is a prudent step to prevent unwanted changes to the database. Then, the user must request data from a particular field within the database. This represents the first data request by the user. Again, it is requested via the first interface. This also requires the user to remember the relevant command and its arguments. Then, the user must wait to find out if the data request is successful or if it failed.
If the first data request is successful, then the user must evaluate the data returned from the field in the database and determine whether it is necessary to modify that data so that the later TI command will be enabled. If the content of the field in the database must be altered, then the user must remember the relevant command and its arguments as well as construct and submit the command. In other words, the user must request a second action, again, via the APXRCV interface. Once the particular field in the database stores the desired value, the user must initiate a TI session. Then, the user must determine whether the TI session has been successfully established. If not, then the user must restore the APXRCV database to its original values. Otherwise, the user must remember the desired TI command and its arguments. In other words, the user must request a third action, but this time it is requested via a second interface (the TI interface). Then the user should terminate the TI session. Then the user should restore the previous values of the APXRCV database, i.e., request a fourth action, again, via the first interface.
A motivation, among others, for the invention is a recognition that the amount of direct user interaction with the monitoring systems can be greatly reduced by providing a liaison interface between the user and the existing interfaces by way of running a script on a machine, e.g., as a retrofit liaison interface. This solves the excessive direct user interaction problems suffered by the known interfaces while avoiding the great costs associated with revising the interfaces per se. The liaison interface automatically interacts with the existing interfaces, i.e., the liaison interface interacts with the existing interfaces without the direct involvement of the human user.
The invention, in part, provides a scripting language for writing scripts that when run on a machine generate such a liaison interface.
The invention, in part, provides such a scripting language that includes an integration construct data structure that permits commands of discrete interfaces to be integrated in a single script that is to be executed by a machine.
The invention, in part, also provides a computer-readable medium embodied script that includes at least two of the integration construct data structures.
The invention, at least in part, is embodied by providing a computer-readable medium having embodied thereon a script to be processed by a machine connected to a system, the system having at least a first interface for interacting with a user, the computer-readable-medium-embodied script causing the machine to generate a second interface for interacting differently with the user than the first interface, each of the interfaces having at least a set of commands. Such a computer-readable-medium-embodied script comprises: a sequence of executable statements including at least two integration constructs. Each of the integration constructs includes: a first field to identify one of the first interface and the second interface; and a second field to identify at least a command from the corresponding set for the interface identified in the first field.
The invention is also embodied, at least in part, by providing an integration construct data structure readable by a machine, the machine operating upon commands from at least two domains, the integration construct associating a command with a domain where the command is valid. Such an integration construct comprises: a first data object to identify at least a command; and a second data object, linked to the first data object, to identify one of at least a first domain and a second domain as the domain in which the command of the first data object is valid.
The invention is also embodied, at least in part, by providing a method of parsing an executable statement, the executable statement being readable by a machine, the machine operating upon commands from at least two domains. Such a method comprises: examining the executable statement to identify one of at least a first domain and a second domain as the domain in which a command embedded in the executable statement is valid; and examining said executable statement to identify at least said command.